home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / CCITT / 1992 / X / x420.asc < prev    next >
Encoding:
Text File  |  1993-07-15  |  13.4 KB  |  598 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Recommendation X.420
  8.                                     
  9.        MESSAGE HANDLING SYSTEMS: INTERPERSONAL MESSAGING SYSTEM1
  10.  
  11.  
  12.         The establishment....
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.               
  58.  
  59. 1   Recommendation  X.420  and  ISO  10021-7,  Information  Processing  Systems   -   Text
  60.    Communication  -  MOTIS  -  Interpersonal   Messaging   System,   were   developed   in
  61.    close collaboration and are technically aligned, except for  the  differences     noted
  62. in Annex M.
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.         The  Primary  Recipients  heading  field  (D  no   subfields   (i.e.,   elements))
  80. identifies the zero or more users and  DLs  who  are  the  "primary  receipients"  of  the
  81. IPM. It also identifies  the  responses  the  authorizing  users  ask  of  each  of  those
  82. users  and  of  each  member  of  those  DLs.  It  comprises  a  Sequence  of  sub-fields,
  83. each a recipient specifier, one for each primary recipient.
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.         The  Copy  Recipients  heading   field   (D   no   subfields   (i.e.,   elements))
  93. identifies the zero or more users and DLs who are  the  "copy  receipients"  of  the  IPM.
  94. It also identifies the responses  the  authorizing  users  ask  of  each  of  those  users
  95. and of each  member  of  those  DLs.  It  comprises  a  Sequence  of  sub-fields,  each  a
  96. recipient specifier, one for each copy recipient.
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.         The  Obsoleted  IPMs   heading   field   (D   no   subfields   (i.e.,   elements))
  107. identifies zero or more IPMs that the authorizing users of the  present  IPM  consider  it
  108. to obsolete.  It  comprises  a  Sequence  of  sub-fields,  each  an  IPM  identifier,  one
  109. for each IPM.
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.         The   Related   IPMs   heading   field   (D   no   subfields   (i.e.,   elements))
  122. identifies zero or more IPMs that the  authorizing  users  of  the  present  IPM  consider
  123. related to it. It comprises a Sequence of sub-fields, each  an  IPM  identifier,  one  for
  124. each IPM.
  125.  
  126.  
  127.  
  128.         The  Extensions  heading  field  (D  no  extensions   (i.e.,   members))   conveys
  129. information accommodated by no other  heading  field.  It  comprises  a  Set  of  zero  or
  130. more heading extensions (or extensions), each conveying one such information item.
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.         The  Parameters  and  Data  components   are   Externals   (see   clause   32   of
  147. Recommendation  X.208).  Their  Direct-reference  components  shall  be   present,   their
  148. Indirect-reference and Data-value-descriptor components absent.
  149.  
  150.  
  151.         An  instance  of  the  macro's  value  notation  defines  the  Object   Identifier
  152. that appears  as  the  Direct-reference  component  of  the  Data  component  of  such  an
  153. (Externally Defined) body part.  The  Object  Identifier  identifies  the  encoding  rules
  154. for the body part.  Those  body  parts  whose  types  this  Recommendation  defines  shall
  155. be encoded using ASN.1's basic encoding rules.
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. 2.      If an Externally  Defined  body  part  has  a  Parameters  component,  the  Object
  165. Identifier in its Direct-reference  component  is  allocated  at  the  same  time  and  by
  166. the same  naming  authority  as  that  in  the  Direct-reference  component  of  the  Data
  167. component.
  168.  
  169. 3.      
  170.  
  171.  
  172. 4.
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.         The IPM to which  an  IPN  refers  is  called  the  subject  IMP.  Only  a  UA  to
  199. which the subject IPM is actually  delivered  shall  originate  an  IPN  relating  to  it,
  200. and  it  shall  originate  at  most  one  such  IPN  which  shall  be  conveyed   to   the
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212. subject IPM's originator alone.
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219. is present and has as its  value  either  an  O/R  name  of  the  preferred  recipient  as
  220. a result of which the  subject  IPM  was  delivered  to  the  user  on  whose  behalf  the
  221. examination is performed or, if the  IPM  reached  the  user  because  of  his  membership
  222. in a DL, an O/R  name  appearing  in  the  message's  DL  expansion  history  (see  clause
  223. 8.3.1.1.1.7 of Recommendation X.411).
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.         The   report   received   may   concern   any   of   the   following    previously
  236. originated by the report's recipients:
  237.  
  238. a)      A probe concerning a  message  whose  content  was  an  IPM  that  was  originated
  239.        with the Originate Probe abstract operation.
  240.  
  241. b)      A  message  whose  content  was  an  NRN  that  was  originated  as  a  result  of
  242.        auto-discard or auto-forward.
  243.  
  244. c)      A message whose  content  was  an  RN  that  was  originated  with  the  Originate
  245.        RN abstract operation or by auto-acknowledgment.
  246.  
  247.  
  248. d)      a message whose content  was  an  IPM  that  was  originated  with  the  Originate
  249.        IPM abstract operation or by auto-forwarding.
  250.  
  251. a)      Envelope (M):
  252.  
  253. b)      Undelivered-object
  254.  
  255.  
  256.  
  257.  
  258.  
  259.         This  conditional  argument  shall  be  present  if,  and  only  if,   the   Auto-
  260. forward-IPMs argument has the value true.
  261.  
  262.         This abstract operation has no results.
  263.  
  264. Note  -  This  abstract  operation  is  intended  to   define   the   essence   of   auto-
  265. forwarding, and not to preclude the  provision  of  more  sophisticated  auto-  forwarding
  266. capabilities, e.g., like those of an MS.
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281. 3. The MTS  supplies  import  and  export  ports.  However,  since  those  ports  are  not
  282. formally  defined  (in  Recommendation  X.411),  they  are  not  included  in  the  formal
  283. refinement above.
  284.  
  285. 16.1    Interpersonnal Messaging System User Agent
  286.  
  287.    An Interpersonal Messaging System  user  agent  (IPMS  UA)  is  a  UA  tailored  so  as
  288. to better assist a single  user  to  engage  in  Interpersonal  Messaging.  It  helps  him
  289. originate,  receive,  or  both  originate  and  receive  messages  containing  information
  290. objects of the types defined in section two.
  291.  
  292.    ipms-ua.....
  293.  
  294.  
  295.  
  296.                ::= id-ot-tlma
  297.  
  298.         The IPMS comprises any number of TLMAs.
  299.  
  300. NOTES
  301.  
  302. 1.      A  TLMA  consumes  import  and  export  ports.  However,  since  those  ports  are
  303. not  formally  defined  (in  Recommendation  X.411),  they  are  not   included   in   the
  304. formal definition of TLMA above.
  305.  
  306. 2.      A  TLMA's  miscellanea  port  is  defined  in  Recommendation  T.330.  It  is  not
  307. part of the IPMS Abstract  Service  in  its  most  general  form,  which  is  the  subject
  308. of this  Recommendation.  Rather  it  embodies  capabilities  available  only  to  a  TLMA
  309. user. For this reason,  it  is  not  considered  further  here  and  is  not  included  in
  310. the formal refinement of the IPMS found in clause 16.
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.                     management [S]
  318.  
  319.               ::= id-ot-tlxau
  320.  
  321.         The IPMS comprises any number of TLXAUs.
  322.  
  323. Note - A  TLXAU  consumes  import  and  export  ports.  However,  since  those  ports  are
  324. not  formally  defined  (in  Recommendation  X.411),  they  are  not   included   in   the
  325. formal definition of TLXAU above.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.               ::= id-ot-pdau
  349.  
  350.         The IPMS comprises any number of PDAUs.
  351.  
  352. Note -  A  PDAU  consumes  import  and  export  ports.  However,  since  those  ports  are
  353. not  formally  defined  (in  Recommendation  X.411),  they  are  not   included   in   the
  354. formal definition of PDAU above.
  355.  
  356.  
  357.         If the  Blind  Copy  Recipients  heading  field  of  the  IPM  identifies  one  or
  358. more users  and  DLs,  the  UA  shall  invoke  Message  Submission  multiple  times,  upon
  359. each occasion varying the heading field so  as  to  comply  with  the  information  hiding
  360. requirements of clause 7.2.6.
  361.  
  362.         The results of Originate IPM shall be as follows:
  363.  
  364.  
  365.  
  366.  
  367.  
  368.         The  UA  shall  suppress  auto-forwarding  if,  and  only  if,  the  IPM   to   be
  369. forwarded itself  contains  a  forwarding  IPM  that  the  UA  previously  created.  Auto-
  370. forwarding shall be  suppressed  whether  the  forwarding  IPM  appears  (directly)  in  a
  371. Message body part of the IPM to be forwarded, or  (nested)  in  a  Message  body  part  of
  372. the IPM that appears in such a body part.
  373.  
  374.  
  375.  
  376. 19.4    Auto-forwarding
  377.  
  378.         An    IPMS     MS     shall     perform     the     Auto-forward     action     of
  379. Recommendation  X.413  as  specified  in  clause  18.5.3.  It  makes  use  of  the  other-
  380. parameters  component  of  the  Auto-forward-registration  argument  of  the  Register  MS
  381. abstract  operation  of  the  MS  Abstract  Service.  The  data   type   of   the   other-
  382. parameters component is defined as follows:
  383.  
  384.         Forwarded Info  ::= SET {
  385.               auto-forwarding-comment [0] Auto Forward Comment OPTIONAL,
  386.                            cover-note [1] IA5TextBodyPart OPTIONAL,
  387.               this-imp-prefex [2] PrintableString (SIZE
  388.               (1.. ub-ipm-identifier-suffix)) OPTIONAL }
  389.  
  390.         In addition, the MS shall satisfy the following requirements:
  391.  
  392. a)      Submit an NRN even if it retains a copy of the forwarded IPM.
  393.  
  394. b)       Draw  the  NRN's  Auto-forward  Comment  field,   if   any,   from   the   other-
  395.        parameters component.
  396.  
  397. c)      Draw the cover-note,  if  any,  to  be  included  with  the  forwarded  IPM,  from
  398.        the other-parameters component.
  399.  
  400. d)       Prefix  the  User-relative-identifier  component  of  the  This  IPM   field   of
  401.        the forwarding IPM's heading with, if present, the This-ipm-prefix.
  402.  
  403. NOTE  -  An   (IPMS)   MS   performs   neither   auto-discard   nor   auto-acknowledgment,
  404. except possibly as a local matter.
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416. iii)    The  Parameters  element  of  any  Videotex  body  part  (of  an  IPM)  lacks  the
  417.        Syntax member.
  418.  
  419. iv)     Every.......
  420.  
  421.  
  422.  
  423.  
  424.  
  425. v)       The  Data  element  of  any  Message  body  part  (of  an  IPM)  satisfies  these
  426.        same constraints (recursively).
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.         A  secondary  object  that  submits  a  probe  concerning  a  message   containing
  446. an IPM or IPN  shall  specify  as  the  length  of  the  message's  content  the  size  in
  447. octets  of  the  encoding  of  the  instance  in  question  of  the  InformationOjbect  of
  448. section  two  (a  choice  of  an  IPM  or  an  IPN)  when  the  Basic  Encoding  Rules  of
  449. Recommendation X.209 are followed. If those rules permit  several  (e.g.,  both  primitive
  450. and  constructed)  encodings  of  that   InformationObject,   the   content   length   may
  451. reflect any one of them.
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466. b)      (Forwarded) Message body  part:  The  basic  EITs  (if  any)  and  NBPs  (if  any)
  467.        of a Message body part shall be those of the forwarded message.
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485. d)      Basic......
  486.  
  487.  
  488.  
  489.  
  490. e)      Encrypted body part:  The  effect  of  an  Encrypted  body  part  upon  the  basic
  491.        EITs and NBPs to be specified is for further study.
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.         The  Incomplete  Copy  heading  extension,  by  its   presence,   indicates   that
  516. one of more body parts or heading  fields  are  absent  from  the  Body  of  (the  present
  517. instance of) the IPM. The extension comprises a Null (by default).
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.         All  of  the  attributes  defined  in  this  annex,  except  those   corresponding
  539. to extended  body  part  types  (which  cannot  be  enumerated;  see  clause  C.3.6),  are
  540. listed alphabetically,  for  reference,  in  the  first  column  of  Table  3/X.420.  This
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547. table records their presence in a  delivered  message  entry.  None  of  them  appears  in
  548. either  a  delivered  report  entry  or  a  returned  content  entry.  See  Recommendation
  549. X.413 for an elaboration of the table's legend.
  550.  
  551.  
  552.  
  553.  
  554.         To  each  extended  body  part  type  there   correspond   two   attributes.   The
  555. first attribute  is  denoted  by  the  Object  Identifier  that  is  the  Direct-reference
  556. component  (again,  see  clause  7.3.12)  of  the  External  that  constitutes  the   Data
  557. component of a body part of that type. The content of this first attribute  is  that  Data
  558. component. The  second  attribute  is  denoted  by  the  Object  Identifier  that  is  the
  559. Direct-reference   component   of   the   External   that   constitutes   the   Parameters
  560. component of a body part of that type. The  content  of  this  second  attribute  is  that
  561. Parameters component.
  562.  
  563.         An  MS  that  supports   one   of   these   body   parts   shall   maintain   both
  564. attributes for an information object that it holds if, and  only  if,  that  object  is  a
  565. message whose content is an IPM whose Body contains one or more body  parts  of  the  type
  566. that corresponds to that  attribute.  It  shall  maintain  one  value  of  each  attribute
  567. for each such body part.
  568.  
  569.  
  570. -- Message Store Realization
  571.  
  572. ForwardedInfo ::= SET {
  573.       auto-forwarding-comment [0]
  574.           AutoForwardComment OPTIONAL,
  575.       cover-note [1]
  576.           IA5TextBody Part OPTIONAL,
  577.       this-ipm-prefix [2]
  578.           PrintableString (SIZE (1..
  579.               ub-ipm-identifier-suffix))
  580.               OPTIONAL }
  581.  
  582. END -- of IPMSInformationObjects
  583.  
  584.  
  585.  
  586. a)       The   ISO   International   Standard   corresponding   to   this   Recommendation
  587.        defines  General  Text  and  Line  Text  body  parts,  while  this   Recommendation
  588.        does not.
  589.  
  590. b)     The  upper  bounds  of  Annex  K  are  an  integral  part  of  this  Recommendation
  591.        but are not a part of the corresponding ISO International Standard.
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.